На днях компания VMware обновила свой главный документ, касающийся обеспечению безопасности виртуальных сред и самой платформы виртуализации - VMware vSphere 7 Security Configuration Guide. Напомним, что о его прошлой версии осенью прошлого года мы писали вот тут.

Давайте посмотрим, что появилось нового в обновленном SCG для vSphere 7, который традиционно состоит из PDF-файла описания и XLS-файла настроек, рекомендаций и пояснений:

• Исправлены ошибки в рекомендациях PowerCLI для аудита виртуальных машин.
• Добавлена вкладка "Deprecated" - там теперь будут те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

• Настройка svga.vgaOnly перемещена в Deprecated. Она ограничивает ВМ на использование только VGA-разрешений, а многие современные ОС этого очень не любят (могут даже отключить отображение картинки в этом случае).
• Добавлены и обновлены рекомендации по отключению сервисных служб SLP и CIM на сервере ESXi. Эти протоколы часто не используются (их не используют и продукты VMware), поэтому лучше их отключить.
• Добавлены рекомендации по изоляции сети. Раньше как-то само собой подразумевалось, что нужно разделять сети управления, vMotion и vSAN, теперь же это формализовано в документе. Там же рекомендовано и физическое разделение сетей.
• Добавлена рекомендация по использованию только тех продуктов, старые версии которых еще официально поддерживаются со стороны VMware (например, вы можете выполнить все рекомендации и накатить все обновления, но использовать старый ESXi 5, что по понятным причинам небезопасно).
• Добавлено руководство по использованию модулей Trusted Platform Modules 2.0 (TPM).
• Снова возвращена рекомендация vm-7.pci-passthrough, касающаяся прямого доступа виртуальных машин к оборудованию, в частности шине PCIe.
• Добавлено руководство по отключению интерфейсов DCLI, если вы не используете его на vCenter Server. Также вам не нужно держать SSH постоянно открытым, так как в vSphere широкий и защищенный API, который вы можете использовать в разных фреймворках и утилитах.

Скачать VMware vSphere 7 Security Configuration Guide (как и руководства для других версий vSphere) можно по этой ссылке. Подробнее о документе также можно почитать тут.

Многие администраторы VMware vSphere знают, что для организации кластеров Windows Server Failover Clusters (WSFC) нужен эксклюзивный доступ к LUN, а значит на уровне виртуальной инфраструктуры подходили только RDM-диски. Ранее эти кластеры назывались MSCS, мы писали об их организации в виртуальной среде вот тут.

Такая ситуация была из-за того, что WSFC использует механизм резервация SCSI-3 Persistent Reservations, который координирует доступ к общему дисковому ресурсы. С другой стороны, VMFS использует собственный механизм блокировки LUN, поэтому команды WSFC перехватываются и отменяются, если используются диски VMDK. Поэтому RDM-устройства и использовались как средство маппинга дисков виртуальных машин к физическому устройству LUN.

Оказывается, ситуация поменялась с выпуском VMware vSphere 7, где появился механизм Clustered VMDK. Он позволяет командам SCSI3-PR выполняться и применяться к виртуальному диску VMDK, поэтому вам не нужен отдельный LUN.

К сожалению, все это работает только на хранилищах Fibre Channel.

Чтобы это начать использовать, на уровне датастора надо установить параметр "Clustered VMDK Supported":

Далее нужно понимать следующие условия и ограничения:

• Параметр кластера Windows Cluster "QuorumArbitrationTimeMax" должен быть выставлен в значение 60.
• LUN за этим датастором должен поддерживать команды ATS SCSI (как правило, это всегда поддерживается).
• LUN должен поддерживать резервации типа Write Exclusive All Resgistrants (WEAR).
• VMDK-диски должны быть типа Eager Zeroed Thick и виртуальные машины должны быть как минимум в режиме совместимости с vSphere.
• Не презентуйте LUN, которые используются как кластерные VMDK, для хостов ESXi версий ниже 7.0.
• Не комбинируйте датасторы для clustered и non-clustered VMDK на одном общем кластерном хранилище.
• Выделяйте один датастор на один кластер WSFC, не шарьте один датастор между несколькими инстансами кластеров WSFC.

Максимумы конфигураций для таких кластеров WSFC следующие:

Надо помнить еще о следующих ограничениях (более подробно тут):

• Конфигурация Cluster in a Box (CIB) не поддерживается. То есть надо настроить правила anti-affinity DRS Rules, чтобы разделить узлы кластера / виртуальные машины по разным хостам ESXi. Если вы попробуете такую ВМ с помощью vMotion переместить, то миграция завершится неудачно.
• Горячее расширение VMDK кластерной ВМ не поддерживается.
• Не поддерживается Storage vMotion и снапшоты.
• VMFS 5 и более ранние версии не поддерживаются.

На сайте VMware Labs появился интересный инструмент Virtualized High Performance Computing Toolkit, который может оказаться полезен компаниям, использующим VMware vSphere для организации высокопроизводительных вычислений (High Performance Computing, HPC). Такие комплексные вычислительные задачи, как правило, вовлекают параллельные вычисления, аппаратное ускорение (такое как GPU и FPGA), а также используют высокоскоростные каналы, такие как RDMA.

Все это требует определенных конфигураций VMware vSphere, для настройки которых и нужно данное средство. С помощью него, используя vSphere API, можно дать администраторам инструменты по сопровождению задач HPC, таких как клонирование ВМ, настройка Latency Sensitivity, сайзинг виртуальных машин по CPU и памяти и многое другое.

Основные возможности тулкита:

• Настройка устройств PCIe в режиме DirectPath I/O, таких как GPGPU, FPGA и RDMA
• Настройка NVIDIA vGPU
• Настройка RDMA SR-IOV (Single Root I/O Virtualization)
• Настройка PVRDMA (Paravirtualized RDMA)
• Простое создание и уничтожение кластеров HPC с помощью файлов конфигураций
• Выполнение задач vSphere, таких как клонирование, настройка vCPU, памяти, резерваций, shares, Latency Sensitivity, обычного и распределенного виртуального коммутатора, сетевых адаптеров и конфигураций

Например, клонирование 4 виртуальных машин с заданными кастомизациями CPU и памяти, а также добавлением NVIDIA vGPU с профилем grid_p100-4q выглядит так:

vhpc_toolkit> clone --template vhpc_clone --datacenter HPC_Datacenter --cluster COMPUTE_GPU_Cluster --datastore COMPUTE01_vsanDatastore --memory 8 --cpu 8 –-file VM-file
vhpc_toolkit> vgpu --add --profile grid_p100-4q --file VM-file

Для использования тулкита вам понадобится ОС Linux или Mac. Скачать Virtualized High Performance Computing Toolkit можно по этой ссылке.

Многие администраторы в крупных инфраструктурах сталкиваются с проблемами назначения и обновления лицензий компонентов VMware vSphere - серверов ESXi и vCenter. Это можно сделать в графическом интерфейсе vSphere Client, но когда у вас много хостов, это становится муторным делом, во время которого легко ошибиться или просто устать:) Давайте посмотрим, как можно просто это делать через PowerCLI...

Иногда администратор VMware vSphere задается вопросом о происхождении виртуальной машины - из какой родительской ВМ/шаблона она была клонирована? Вильям Лам разбирает это в своей статье, приведем вкратце его метод определения происхождения ВМ.

Как вы знаете, бывает три типа клонирования виртуальных машин в VMware vSphere:

• Full Clone - это полный клон, то есть независимая копия виртуальной машины, у которой нет ничего связанного с родительской ВМ, это просто ее полная копия.
• Linked Clone - это копия виртуальной машины, которая имеет общие диски с родительской, доступные на чтение (это экономит пространство и позволяет просто откатываться к родительскому образу). Уникальные данные эта машина хранит в собственных дельта-дисках.
• Instant Clone - это независимая копия виртуальной машины, которая начинает исполняться с какого-то момента и отделяется от основной машины. Для этого используются техники in-memory cloning и copy-on-write, которые используются также и для связанных клонов.

Чтобы найти источник клонированной машины, нужно проанализировать события vCenter Server Events. Вот какие они бывают касательно клонов:

• VmClonedEvent - появляется, когда происходит создание Full Clone или Linked Clone.
• com.vmware.vc.VmInstantClonedEvent - происходит при созданиии Instant Clone.
• VmDeployedEvent - вызывается, когда виртуальная машина развертывается из шаблона (vSphere Template или Content Library Template).

На базе анализа этих трех событий в истории vCenter Вильям Лам создал PowerCLI-функцию Get-VMCloneInfo, с помощью которой можно узнать родителя для виртуальной машины, если она была клонирована.

Устанавливаем ее простой командой:

Install-Script VMCloneInfo

На входе эта функция принимает имя ВМ, которую мы хотим проанализировать. Такой вывод мы получим, если машина не была клонирована:

> Get-VMCloneInfo -VMName "SourceVM"

Unable to find any cloning information for SourceVM, VM may not have been cloned or vCenter Events have rolled over

Так будет выглядеть вывод по полному клону:

> Get-VMCloneInfo -VMName "Full-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVM 1/3/2021 1:13:00 PM VSPHERE.LOCAL\Administrator

Так мы узнаем, что машина является связанным клоном:

> Get-VMCloneInfo -VMName "Linked-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Linked SourceVM 1/3/2021 1:13:14 PM VSPHERE.LOCAL\Administrator

Так - что Instant-клоном:

> Get-VMCloneInfo -VMName "Instant-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Instant SourceVM2 1/3/2021 1:12:44 PM VSPHERE.LOCAL\Administrator

Вот пример того, что машина была клонирована из шаблона vSphere Template:

> Get-VMCloneInfo -VMName "VMTX-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVMTXTemplate 1/3/2021 2:20:31 PM VSPHERE.LOCAL\Administrator

А вот - что из шаблона Content Library VM Template:

> Get-VMCloneInfo -VMName "VMTemplate-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVMTemplate 1/3/2021 2:23:41 PM VSPHERE.LOCAL\Administrator

Компания VMware выпустила недавно интересный документ "VMware vSphere 7.0 U1 Tagging Best Practices", описывающий улучшения, которые были сделаны в VMware vSphere 7.0 U1 в плане производительности операций при работе с тэгами.

Вкратце, было сделано 3 основных улучшения:

• Увеличена производительность при создании тэгов и категорий по сравнению с vSphere 6.7 U3.
• Производительность вывода тэгов через API улучшилась по сравнению с vSphere 6.7 U3.
• Теперь доступна паджинация вывода API, что позволяет упростить и ускорить получение данных.

Для иллюстрации улучшений на рисунке ниже приведена картина задержек (latency) при привязывании 15 тэгов к 5 000 виртуальным машинам в vSphere 6.7 U3 (где время линейно увеличивалось с ростом числа тэгов) и vSphere 7.0 Update 1, где время оставалось практически неизменным.

Скачать отчет VMware vSphere 7.0 U1 Tagging Best Practices можно по этой ссылке.

Компания VMware опубликовала полезный FAQ, ссылка на который может в любой момент понадобиться администратору VMware vSphere для понимания различных аспектов системного хранилища серверов VMware ESXi.

Давайте посмотрим, на какие вопросы там можно найти ответы:

• Что изменилось в системном хранилище ESXi 7 по сравнению с прошлыми версиями? Мы об этом подробно писали тут.
• Что случится с разметкой системного хранилища при апгрейде на vSphere 7? Ответ тут и на этой картинке:

• Какое хранилище рекомендуется в качестве системного для ESXi?
• Что насчет устройств USB/SD? Можно ли использовать SD-карту для системного хранилища? (Спойлер: лучше не надо).
• Почему вы можете увидеть ситуацию, что хосты ESXi в "Degraded Mode"?
• Что вообще означает Degraded Mode?
• Можно ли добавлять локальное хранилище после апгрейда на ESXi 7? (Спойлер: да)
• Что делать, если хост в Degraded Mode, а хранилища вообще не видно? (Спойлер: смотреть External Syslog, NetDump Collector или Core Dump Partition)
• Если вы используете vSphere AutoDeploy, то как работает развертывание системного хранилища? Подробнее об этом вот тут

Интересно, что продукты VMware vSphere и VMware vSAN имеют разные списки совместимости оборудования (HCL - Hardware Compatibility Lists). Ronald de Jong в своем блоге описал ситуацию, когда у него драйвер SCSI-контроллера подошел для vSphere, но не подошел для vSAN.

После установки обновления драйвера для VMware vSphere через VMware Lifecycle Manager он получил вот такие ворнинги для vSAN в vSphere Client:

Драйвер smartpqi (70.4000.0.100-4vmw.701.0.0.17325551) уже подходит для vSphere, но еще не провалидирован для решения vSAN. В этом можно убедиться в списке совместимости для vSAN по этой ссылке, где есть только старый драйвер (3vmw):

Если же заглянуть в список совместимости для vSphere, то там будет обозначена поддержка старого и нового драйверов:

Таким образом, нужно провести даунгрейд драйвера, чтобы он подходил и для vSphere, и для vSAN. Сначала идем на Patch Portal и находим там нужное обновление в виде VIB-пакета:

Вот этот драйвер:

После загрузки в консоли ESXi запускаем установщик VIB-пакета командой:

esxcli software vib install -d /vmfs/volumes/vsanDatastore/tmp/VMware-ESXi-7.0U1-16850804-depot.zip -n=smartpqi

После этого все ворнинги по совместимости драйвера исчезнут:

Но в Lifecycle Manager все еще будут висеть предупреждения о необходимости поставить последнюю версию драйвера и проапдейтить ESXi:

Некоторое время назад мы писали об улучшении технологии горячей миграции vMotion (тут и тут) в последней версии VMware vSphere 7 Update 1. Сегодня мы вкратце расскажем о вариантах переноса рабочих нагрузок в кластер хранилищ VMware vSAN на базе вот этой заметки.

Первое, что вы должны решить - это в каком рабочем процессе вы будете мигрировать виртуальные машины с помощью vMotion: за один шаг (хранилище+сервер) или за два (сначала сервер, потом хранилище).

1. Миграция в два шага (Two-Step Migrations)

При выборе миграции виртуальной машины у нас есть опция изменения либо сервера ESXi машины, либо ее хранилища, либо и того, и другого:

• Change compute resource only - это первый шаг миграции для случая, когда не-vSAN хранилище может быть презентовано существующему кластеру vSAN. Также это может быть востребовано в рамках топологии VMware vSAN HCI Mesh, где хранилище монтируется удаленному кластеру vSAN.
• Change storage only - это второй шаг миграции, когда машина на хосте ESXi уже находится в кластере vSAN, и мы выполняем перенос ее VMDK уже на собственные хранилища кластера.

Надо сказать, что миграция машин в два шага имеет бОльшую гранулярность, что позволит вам получить промежуточный результат и зафиксировать результат в середине (например, смигрированная на другой хост, но не хранилище машина), что может сэкономить время при повторной попытке миграции в случае каких-то проблем.

2. Миграция в один шаг

Этот способ миграции реализуется, когда вы выбираете опцию Change both compute resource and storage или Cross vCenter Server export. Надо понимать, что процесс этот весьма затратный, и выбирать этот вариант можно, когда у вас есть большой запас по ресурсам и времени для вычислительных ресурсов и ресурсов хранилищ. Ну или когда вы не можете расшарить хранилище между двумя разными кластерами vSphere / vSAN.

Удобство это способа еще и в том, что если у вас есть много времени на миграцию, то можно просто поставить vMotion для нужных нагрузок, и все будет постепенно переезжать без участия администратора.

Также для переноса нагрузок между разными инфраструктурами есть опция Cross vCenter Server export. В обновлении VMware vSphere 7 Update 1c главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.

Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.

Если вы решили сделать пакетную миграцию виртуальных машин в vSphere Client, то нужно для кластера или пула ресурсов перейти на вкладку VMs и с шифтом выбрать группу ВМ для миграции, после чего из контекстного меню выбрать Migrate...:

Надо сказать, что машины одной группы можно мигрировать только в одинаковом состоянии (Powered on или Powered off), поэтому удобно отсортировать их по колонке State.

Ну и в заключение - картинка об улучшении технологии vMotion с момента ее появления в 2003 году:

VMware выпустила 2 новых экзамена VMware Certified Advanced Professional (VCAP)

На днях компания VMware объявила о релизе обновленных версий экзаменов VMware Certified Advanced Professional (VCAP). Первый - Advanced Design VMware vSphere 7.x (3V0-21.21) - подтверждает знание кандидатами принципов разработки концептуальной архитектуры VMware vSphere 7.x с учетом требований заказчика, возможность определения функциональных и нефункциональных требований для создания логического дизайна инфраструктуры, а также создания физической архитектуры с учетом всего этого.

Этот экзамен ведет к сертификации VMware Certified Advanced Professional – Data Center Virtualization Design 2021:

Экзамен содержит 60 вопросов и заданий, 300 очков проходной балл и 150 минут на сдачу. Описание экзамена (Blueprint) находится вот тут.

Второй выпущенный экзамен - это  Advanced Deploy VMware vSphere 7.x (3V0-22.21). Он проверяет знания по планированию и развертыванию решения vSphere 7.x, включая задачи по администрированию, оптимизации и траблшутингу. Тут уже больше про Day-2 Operations.

Экзамен требуется для сертификации VMware Certified Advanced Professional – Data Center Virtualization 2021 Deploy:

Здесь уже 17 заданий на базе лабораторных работ, 300 очков проходной балл и 205 минут на сдачу. Руководство по экзамену доступно тут.

Решение для виртуализации сетей VMware NSX-T, в отличие от его vSphere-версии NSX-V, не имеет графического интерфейса для настройки отсылки логов на серверы Syslog.

Graham Smith написал краткую заметку о настройке Syslog для решения VMware NSX-T, включая NSX-T Manager, узлы Edge Nodes и серверы ESXi.

Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware Log Insight. Сначала заходим по SSH на NSX-T Manager и выполняем там следующую команду, указав IP-адрес сервера Log Insight:

MulNSXT01> set logging-server 192.168.10.8 proto udp level info 
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На узлах Edge Nodes также нужно выполнить такую же команду, зайдя по SSH:

DCA-MulNSXT-ESG01> set logging-server 192.168.10.8 proto udp level info
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На серверах ESXi процесс выглядит несколько иначе. Нужно выполнить вот такую последовательность команд:

[root@DCA-MulComp01:~] esxcli network firewall ruleset set -r syslog -e true
[root@DCA-MulComp01:~] esxcli system syslog config set --loghost=udp://192.168.10.8:514
[root@DCA-MulComp01:~] esxcli system syslog reload
[root@DCA-MulComp01:~] esxcli system syslog mark -s "This is a test message"

Первая команда разрешает в фаерволе трафик Syslog, вторая - настраивает сервер адрес сервера, третья - подхватывает настройки, ну а четвертая - отсылает тестовое сообщение, чтобы можно было проверить работоспособность механизма Syslog со стороны Log Insight.

Там это тестовое сообщение можно увидеть в разделе Events:

Чтобы проверить логирование на стороне фаервола, можно создать простое правило с тестовым тэгом:

Далее в Log Insight можно увидеть это событие, поискав по этому тегу:

Чтобы проверить конфигурацию Syslog на стороне сервера ESXi, нужно выполнить следующую команду:

[root@DCA-MulComp01:~] esxcli system syslog config get
   Check Certificate Revocation: false
   Default Network Retry Timeout: 180
   Dropped Log File Rotation Size: 100
   Dropped Log File Rotations: 10
   Enforce SSLCertificates: true
   Local Log Output: /scratch/log
   Local Log Output Is Configured: false
   Local Log Output Is Persistent: true
   Local Logging Default Rotation Size: 1024
   Local Logging Default Rotations: 8
   Log To Unique Subdirectory: false
   Message Queue Drop Mark: 90
   Remote Host: udp://192.168.10.8:514
   Strict X509Compliance: false

На стороне NSX-T Manager и на узлах Edge Nodes конфигурацию Syslog можно проверить такой командой:

DCA-MulNSXT-ESG01> get logging-servers 
Mon Dec 28 2020 UTC 17:37:16.600
192.168.10.8:514 proto udp level info

Еще в 2015 году мы писали о документе "VMware NSX for vSphere Network Virtualization Design Guide", в котором был рассмотрен референсный дизайн инфраструктуры виртуализации сетей в виртуальном датацентре и описывалась архитектура решения NSX на физическом и логическом уровнях. Тогда этот документ занимал 160 страниц.

С тех пор много всего поменялось (решение NSX разделилось на NSX-T и NSX-V), функциональность продуктов для виртуализации сетей существенно расширилась, поэтому выпущенный недавно компанией VMware новый документ "VMware NSX-T Reference Design Guide" теперь занимает 300 страниц! Доступен он абсолютно бесплатно и, по-сути, представляет собой книгу о продукте NSX-T:

Основные корневые разделы документа:

• NSX-T Architecture Components
• NSX-T Logical Switching
• NSX-T Logical Routing
• NSX-T Security
• NSX-T Load Balancer
• NSX-T Design Considerations
• NSX-T Performance & Optimization

Если вы администратор решения VMware NSX на большом предприятии, то это самая лучшая книга, чтобы почитать на новогодние праздники:)

Скачать VMware NSX-T Reference Design Guide можно по этой ссылке.

Многие администраторы виртуальной инфраструктуры VMware vSphere при планировании апгрейда не выясняют важных моментов, касающихся совместимости продуктов и так называемых upgrade paths, то есть поддерживаемых производителем рабочих процессов обновления платформы. В этой статье мы расскажем о том, что нужно выяснить перед апгрейдом...

Большинство администраторов, которым требуется управление виртуальной инфраструктурой VMware vSphere с помощью сценариев используют интерфейс VMware PowerCLI, который является оберткой движка PowerShell. Это требует наличие отдельного хоста, с которого идет исполнение сценариев, а также часто требуются такие сервисы, как vRealize Orchestrator и vRealize Automation.

Поэтому, начиная с VMware vSphere 6.7, появился новый Open Source интерфейс для управления виртуальной средой - Script Runtime Service (SRS). Он представляет собой Kubernetes-приложение для управления инстансами PowerCLI и вызова командлетов через REST API.

Интерфейс SRS позволит интегрировать управление исполнением сценариев PowerCLI в vSphere Client для виртуальных машин и приложений.

SRS создает отдельное пространство имен в кластере Kubernetes, которое позволяет PowerCLI работать как Kubernetes pod. Этот легковесный PowerCLI pod реализуется как образ контейнера, который имеет все модули PowerCLI и требует только необходимые управляющие компоненты, трансформирующие ввод и вывод для сценариев, а также управляющие исполнением запрошенного сценария.

Первоначальная инсталляция SRS запускает задачу Kubernetes, которая регистрирует SRS в сервисах провайдера идентификации vSphere SSO. Единожды аутентифицированные клиенты SRS API автоматически включаются в список доверенных на серверах vCenter.

Надо отметить, что сейчас SRS находится еще в ранней стадии разработки и не работает с vSphere with Tanzu (поэтому не развертывайте его со службами Supervisor Cluster).

Попробовать работу с движком SRS можно двумя путями:

1. Устанавливаете SRS в кластере Kubernetes на любую из машин (инструкции здесь)

2. Устанавливаете SRS на специальным образом подготовленную виртуальную машину на базе Photon OS (инструкции тут).

Начать экспериментировать с SRS API можно, перейдя по ссылке:

https://{SRS-IP}/swagger/index.html

SRS использует механизм vCenter Server SSO для идентификации и аутентификации. У любого пользователя с доступом через SSO есть возможность настроить PowerCLI-соединения к серверам vCenter Servers. Как начать это делать описано вот тут.

SRS работает с vSphere 6.7 и более поздними версиями. Сообщить о проблемах вы можете вот тут, а также присодинившись к VMware Code и каналу в Slack.

Вчера мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1c, где главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.

Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.

Один из главных сценариев такой миграции - это горячий перенос виртуальной машины из онпремизной инфраструктуры VMware vSphere в облачную среду VMC on AWS.

Для подобного рода миграций vMotion теперь есть 2 рабочих процесса: миграция ВМ на другой vCenter, а также импорт с целевого vCenter виртуальной машины источника:

Для функциональности XVM поддерживается и режим пакетной миграции, для которого вы можете указать несколько виртуальных машин, выбрать пункт Migrate и начать их одновременный перенос (пункт Cross vCenter Server export):

При миграции можно выбрать новый vCenter или один из уже сохраненных, что очень удобно при миграции групп ВМ в несколько заходов. К сожалению, Saved vCenters сохраняются только в рамках одной пользовательской сессии:

Дальше мастер будет похож на аналогичный в обычном vMotion, где будут выполняться стандартные предпроверки:

Как и при обычном vMotion, вы можете сменить хранилище виртуальной машины, а также ее сеть, чтобы она соответствовала инфраструктуре назначения. Затем начнется стандартная задача миграции:

На целевом vCenter тоже будет отображаться задача по приему vMotion от источника:

На целевом vCenter можно также самостоятельно инициировать прием миграции, выбрав пункт Import VMs из контекстного меню кластера:

Чтобы провести такую миграцию, также надо подключить исходный vCenter:

При успешном подключении вы сможете выбрать виртуальные машины, которые требуется перенести в другой датацентр:

Таким образом, эта функциональность может быть использована для следующих случаев:

• Миграция онпремизных ВМ в облачный датацентр VMC on AWS без необходимости настройки Hybrid Linked Mode (HLM)
• Переход на новую версию платформы vSphere путем переноса рабочих нагрузок со старых серверов
• Миграция ВМ в рамках обновления инфраструктуры VMware Cloud Foundation (VCF)
• Консолидация датацентров или перераспределение их содержимого
• Вывод из эксплуатации старого оборудования со старыми версиями vSphere
• Глобальная перебалансировка виртуальных машин между окружениями VCF
• Миграция инфраструктуры на одно из публичных облаков VMware Cloud

На днях компания VMware выпустила обновление VMware vSphere 7 Update 1c, в котором появилось довольно много всего нового для минорного апдейта.

Давайте посмотрим, что именно:

• Статистики по физическим сетевым адаптерам - добавилось 5 новых параметров (dropRx, dropTx, errorsRx, RxCRCErrors и errorsTx), которые позволяют вам обнаружить сетевые ошибки и предпринять действия по исправлению ситуации.
• Параллельное обновление хостов в кластерах, которые находятся под управлением vSphere Lifecycle Manager. Теперь хосты ESXi под управлением vLCM можно одновременно перевести в режим обслуживания и начать их обновление.
• Advanced Cross vCenter vMotion - это функциональность виртуального модуля Cross vCenter Workload Migration Utility, который был предназначен для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). Теперь эта штука интегрирована в vSphere Client, где удобно работать с миграциями ВМ между датацентрами (поддерживается и пакетная миграция нескольких ВМ):

• Можно подключать сторонние плагины для управления сервисами на платформе vSAN Data Persistence из vSphere Client таким же способом, как вы управляете сервером vCenter.
• Улучшения vSAN DOM scrubber (проверка блоков, к которым давно не было обращений).
• Улучшения Supervisor Cluster:
  • Изоляция пространств имен (Supervisor Namespace Isolation) за счет выделенного маршрутизатора T1 Router (кластеры в сети NSX-T используют для этого новую топологию).
  • Поддержка NSX-T 3.1 для Supervisor Clusters
  • Удалена поддержка Supervisor Cluster версий 1.16.x.
• Улучшения служб Tanzu Kubernetes Grid for vSphere:
  • Поддержка HTTP/HTTPS Proxy – вновь созданные кластеры Tanzu Kubernetes могут использовать глобальные прокси HTTP/HTTPS для исходящего трафика, а также скачивать образы контейнеров из интернет-репозиториев.
  • Вновь созданные кластеры Tanzu Kubernetes из коробки интегрированы со службой vSphere Registry Service. Также с этой службой будут интегрированы кластеры, обновленные до новой версии.
  • Кластеры Tanzu Kubernetes теперь могут монтировать дополнительные тома к виртуальным машинам, что позволяет увеличивать дисковую емкость узлов. Это дает возможность пользователям развертывать большие образы контейнеров, которые больше дефолтного размера в 16 ГБ.

Скачать VMware vSphere 7 Update 1c можно по этой ссылке. Release Notes доступны тут.

Не так давно мы писали о технологии vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Делается это за счет того, что на хостах есть агентские виртуальные машины служб vCLS.

Дункан Эппинг описал ситуацию, когда эти виртуальные машины просто не включаются с ошибкой в консоли vSphere Cleint:

Insufficient resources

Если посмотреть в детали сообщения об ошибке, то там будет примерно следующее:

The target host does not support the virtual machine's current hardware requirements.

Также может быть показано следующее сообщение:

Feature 'MWAIT' was absent, but must be present.

Выходов из этой ситуации может быть два - так как они могут быть обусловлены разными причинами. Причем первый вариант - это официально поддерживаемый со стороны VMware путь устранения проблемы для кластера в целом, а второй - "народный способ" для отдельных ВМ.

Вариант 1:

Для устранения ошибки про Feature 'MWAIT' нужно убедиться, что опция Monitor/MWAIT включена в BIOS (Enabled). vCLS включает EVC на базе виртуальных машин для каждой ВМ. Если же это не помогло или вы не можете это сделать, то нужно использовать метод, описанный ниже.

Вариант 2:

1. Апгрейдим ВМ в плане "Compatibility" до последней версии виртуального железа “VM version 14” (меню апгрейда есть по правой кнопке в vSphere Client).
2. Выбираем нужную ВМ, переходим на вкладку Configure и идем в VMware EVC.
3. Нажимаем "Edit" и выбираем “Yes” для подтверждения изменения настроек
4. Выбираем Disable EVC.
5. Повторяем это для всех виртуальных машин.

Как многие администраторы уже знают, 31 декабря этого года прекращается официальная поддержка технологии Adobe Flash большинством браузеров. Это в первую очередь затрагивает VMware vSphere Web Client, использовавшийся для управления старыми версиями VMware vSphere, когда новая платформа vSphere Client на базе HTML5 еще только развивалась (сейчас это полнофункциональный клиент, а старого веб-клиента больше нет). Напомним, что ранее была прекращена поддержка Internet Explorer.

Вот список продуктов и их версий, которые затронет отсутствие поддержки Flash со стороны браузеров:

В июне этого года, в связи с большим числом заявок от крупных компаний, было решено сделать Workaround для Flash Player. Чтобы включить его для отдельных URL, нужно внести изменения в файл mms.cfg, где следует добавить следующие строчки:

EOLUninstallDisable=1

EnabledAllowList=1

AllowListPreview=1

AllowListUrlPattern=https://FQDN/

Вместо FQDN нужно указать адрес вашего сервера vCenter, vCloud Director или веб-консоли другого продукта.

Вот где находится файл mms.cfg в зависимости от браузера и операционной системы:

Более подробно об этом рассказано в KB 78589.

Какое-то время назад мы писали о полезном документе "Product Lifecycle Matrix", в котором приведены основные моменты касающиеся жизненного цикла продуктов VMware: дата доступности продукта для загрузки, окончание поддержки, завершение технического сопровождения и дата снятия с продаж.

Наш читатель Ser указал на интересный ресурс - это онлайн-тул Product Lifecycle Matrix, который выводит актуальную информацию из указанного документа в возможностью сортировки и фильтрации по нужным колонкам:

Удобно, что в таблице можно не только искать нужный продукт (кстати, не ищите vSphere, потому что там продукты разделяются на ESXi и vCenter), но и экспортировать полученный табличный вид в PDF или CSV, а также вывести его на печать.

Красным отмечены даты у продуктов, для которых поддержка или техническое сопровождение заканчивается в ближайшие 6 месяцев, а фиолетовым - те, у которых поддержка уже закончилась. Обратите внимание, что также есть отдельная вкладка для неподдерживаемых и устаревших продуктов.

В общем, нужная штука - пользуйтесь.

Компания VMware запустила новый ресурс core.vmware.com, посвященный технической информации для администраторов инфраструктуры VMware vSphere, решений vSAN, Horizon, vRealize и других платформ.

На новый портал переехал контент с ресурсов Storage Hub и vSphere Central, который был актуализован и теперь будет регулярно пополняться технической информацией в виде документов и видео.

Например, из интересного:

• VMware vSphere Security Configuration Guide 7 (а также секция Security)
• vMotion Enhancements in vSphere 7 (а также секция vSphere)
• vSphere with Tanzu Proof of Concept и Quick Start Guides

Документов будет много, но основной упор будет делаться на продукты vSphere, vSAN и Cloud Foundation.

Кстати, раз уж речь зашла о документации, расскажем, что VMware потихоньку начинает добавлять техническую документацию по продуктам на русском языке на сайт VMware Docs (мы писали об этом тут). Смотрите, например, что уже есть по vRealize Automation:

В прошлом году мы писали о полезной утилите VMware Configuration Maximums Tool, которая позволяет выводить максимальные конфигурации для различных продуктов VMware. Эта очень полезная штука для администраторов vSphere умеет не только выводить список всех максимумов, но и сравнивать их для разных версий одного продукта.

Для этого нужно выбрать пункт меню "Compare Limits" и указать сравниваемые версии продуктов:

Штука эта очень удобная, но у нее есть большой недостаток - она выводит все конфигурации максимумов (для NSX-T, например, их 274 штуки, поэтому сложно отследить, что именно изменилось).

Поэтому Dale Coghlan написал интересный PowerCLI-модуль VMware.CfgMax, который решает эту проблему - в режиме командной строки можно узнать об изменениях максимумов, а также сделать еще несколько полезных вещей.

После установки модуля можно вывести список доступных продуктов, которые есть на configmax.vmware.com:

Для конкретного продукта можно вывести список его версий/релизов:

Также для конкретной версии можно вывести список категорий максимумов:

С помощью командлета можно вывести все максимумы для конкретного продукта и определенной его версии:

Можно вывести все конфигурации в рамках заданной категории:

Ну и, наконец, с помощью командлета Compare-CfgMaxLimits можно сравнить максимумы конфигураций для разных версий одного продукта:

Как вы видите, тут есть поле CompareStatus, которое и говорит нам, новая ли эта настройка (New), измененная по сравнению с прошлым релизом (Modified), нетронутая (пусто) или удаленная (Deleted) в новой версии.

С помощью параметра New можно, например, вывести все новые настройки:

Параметр Modified выведет только отличающиеся максимумы конфигураций:

Ну а параметр Deleted выведет устаревшие настройки:

Ну и все вместе, без неизмененных значений:

Очень удобная штука, все это также можно экспортировать в формат CSV и сравнивать в Excel. Для этого можно использовать следующую команду:

PS > $product = Get-CfgMaxProduct -Name 'NSX-T Data Center'
PS > $releaseA =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.0.0'
PS > $releaseB =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.1.0'
PS > Compare-CfgMaxLimits -Product $product -Release $releaseA -CompareRelease $releaseB | Export-Csv -Path compare-status.csv -NoTypeInformation

Скачать данный PowerCLI сценарий с примерами вы можете по этой ссылке.

Недавно компания VMware залила на GitHub актуальную версию графики для составления схем и диаграмм в Microsoft Visio и OmniGraffle - VMware Stencils. Иконки и графика доступны еще и в формате Microsoft PowerPoint, а также в векторном формате SVG.

Напомним, что в прошлый раз о стенсилах VMware Stencils мы писали год назад вот тут, а в то время не было версии для OmniGraffl под Mac OS.

Собственно сами ссылки:

• Версия для Microsoft Visio
• Версия для OmniGraffle
• Версия для Microsoft PowerPoint
• Версия в формате SVG

Рекомендации по использованию графических ресурсов:

• Используйте шрифт Metropolis.
• Сначала создавайте текстовые блоки, чтобы понять, что дизайн вписывается в максимальный размер элементов по ширине.
• Не используйте шрифт менее 11 пунктов.
• Не масштабируйте фигуры и иконки - это может привести к их искажениям.
• Не используйте другой формат страницы, это тоже может вызвать сбой в визуализации.

Скачать иконки, графику и диаграммы можно из папок по основной ссылке на GitHub.

На днях один из сотрудников компании VMware сделал аддон Helm Chart под решение vRealize LogInsight Cloud, который позволяет обрабатывать логи кластеров Kubernetes в среде VMware vSphere и TKG (Tanzu Kubernetes Grid).

Работает это решение в двух средах:

• Интегрированные кластеры Tanzu Kubernetes Grid (TKG) K8
• Отдельные инсталляции кластеров K8 на платформах vSphere/AWS

После установки аддона вы можете начать собирать метрики с кластеров TKG и K8 в вашем окружении, а также визуализовывать их на дашбордах наподобие вот такого:

Вообще Helm - это менеджер пакетов для Kubernetes. Это один из лучших путей поиска, шаринга и использования программного обеспечения в кластерах K8. Helm Charts это YAML-манифесты Kubernetes, объединенные в один пакет, который можно развернуть в среде K8. После запаковки установка Helm Chart в кластере производится одной командой helm, которая позволяет просто указать параметры развертывания и апгрейда.

Перед использованием данного средства вам понадобятся:

• Токен для vRealize LogInsight Cloud API
• Helm версии 3.x
• Административный доступ к кластеру Kubernetes

Итак, процедура по шагам:

1. Добавляем репозиторий Chart:

helm repo add loginsight-cloud https://munishpalmakhija.github.io/loginsight-cloud-helm/

2. Получаем файл с переменными из рабочей директории:

helm show values loginsight-cloud/loginsight-cloud-helm > values.yaml

3. Обновляем параметры API Token и другие настройки, специфичные для вашей среды. Начинаем с команды:

cat values.yaml

4. Устанавливаем компонент Chart:

helm install test-vrlic loginsight-cloud/loginsight-cloud-helm -f values.yaml

5. Верифицируем узлы Kubernetes Pods:

kubectl get pods -A | grep test-vrlic

6. Верифицируем релиз Helm:

helm list

Второй рабочий процесс установки (интерактивный режим):

1. Добавляем репозиторий Chart:

helm repo add loginsight-cloud https://munishpalmakhija.github.io/loginsight-cloud-helm/

2. Устанавливаем Chart в интерактивном режиме:

helm install test-vrlic loginsight-cloud/loginsight-cloud-helm --set vrlic.apikey=SETME --set tag.environment=DEMO

3. Верифицируем узлы Kubernetes Pods:

kubectl get pods -A | grep test-vrlic

4. Верифицируем релиз Helm:

helm list

После установки проверяем, что логи идут к LogInsight, это должно выглядеть следующим образом:

Чтобы начать пользоваться пробной бесплатной версией облака vRealize LogInsight Cloud, можно запросить триальную версию тут.

Мы уже много писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1. Сегодня мы посмотрим подробнее, что нового появилось в плане механики резервного копирования виртуальных машин (Data Protection), реализуемой через VMware vStorage API for Data Protection.

1. Функции Network QoS для трафика резервного копирования

Теперь возможности приоритезации трафика Network QoS доступны и для трафика резервного копирования виртуальных машин. Настроить это можно в vSphere Client в разделе System Traffic > Configure > Edit:

Основное назначение данной настройки - дать возможность урезать полосу канала резервного копирования таким образом, чтобы это не влияло существенным образом на трафик производственной среды.

2. Улучшенная обработка задач резервного копирования

Теперь при входе хоста ESXi в режим обслуживания во время резервного копирования есть флаг Entering Maintenance Mode (EMM), что означает, что операции бэкапа должны переключиться на другой хост ESXi, где сессия NFC (network file copy) может быть продолжена. Это автоматическое переключение происходит прозрачно для задачи резервного копирования, но требует от ПО для бэкапа поддержки данного флага, чтобы обнаружить момент переключения.

3.Улучшенное масштабирование для одновременно запущенных задач РК

Для окружений, где параллельно запущено множество задач резервного копирования, ограничения сервера vCenter могут стать проблемой. Использование сервиса VPXA не позволяет кастомизировать буфер памяти для задач, обрабатываемых через vCenter. В апдейте vCenter Server 7.0 U1 теперь можно настраивать буфер памяти, чтобы обрабатывать множество потоков резервного копирования. Например, для 50 одновременных бэкапов нужно использовать 96 MБ памяти.

4. Улучшения vSphere APIs for I/O Filtering (VAIO)

Фреймворк VAIO - это основной интерфейс для партнерских решений, которые могут перехватывать запросы ввода-вывода операционной системы к виртуальному диску. В этом случае команда ввода-вывода (I/O) не будет применена к диску без прохождения через IO Filter, созданный сторонним ПО.

Теперь здесь появились следующие улучшения:

• CIM provider теперь стал 64-битным
• Сами VAIO-фильтры теперь будут распространяться как компоненты, а не VIB-пакеты

Напомним, что в vSphere 7 появилась концепция компонентов вместо отдельных VIB-пакетов. В vSphere 7 компоненты - это набор VIB-пакетов, которые может использовать Lifecycle Manager, чтобы накатывать патчи. Теперь компоненты можно накатывать через esxcli с использованием команды component apply.

На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.

Симптомы переполнения кучи, как правило, следующие:

• Датасторы на хостах показывают статус "Not consumed"
• Виртуальные машины не могут выполнить vMotion
• Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
• При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."

В логе vmkernel.log могут появляться следующие сообщения об ошибках:

• Heap vmfs3 already at its maximum size. Cannot expand
• Heap vmfs3: Maximum allowed growth (#) too small for size (#)
• Failed to initialize VMFS distributed locking on volume #: Out of memory
• Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory

Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:

# vmkfstools -c 10M -d eagerzeroedthick /vmfs/volumes/datastore/eztDisk

Удалить этот диск можно командой:

# vmkfstools -U /vmfs/volumes/datastore/eztDisk

Проблема только в том, что нужно выполнить эту операцию на каждом датасторе каждого хоста. Поэтому есть вот такая команда для всех датасторов и хостов:

# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done

Результат будет примерно таким:

Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:

Maximum allowed growth * too small for size

Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.

Многие администраторы платформы VMware vSphere задаются вопросом - что произойдет, если изменить политику хранилищ (Storage Policy) в кластере vSAN для виртуальной машины? Будет ли после этого выполнена операция по перестроению дисковых объектов (Rebuild), что повлечет дополнительную нагрузку на хранилища и займет время?

Также в некоторых условиях операция Rebuild может не выполняться, но выполняется Resync - добавление новых копий данных, при котором исходные копии данных не изменяются (например, вы увеличиваете значение политики FTT, что влечет создание новых дисковых объектов).

Ответ на этот вопрос зависит от того, какую политику и на что вы меняете. Дункан Эппинг провел полезные тесты в своей лабе, чтобы выяснить, в каких случаях происходит Rebuild/Resync. После каждой операции он через интерфейс командной строки проверял, происходила ли операция ресинхронизации. Далее он свел полученные результаты в таблицу ниже, чтобы при изменении политики администраторы vSAN представляли, что произойдет дальше.

Собственно, таблица:

Многие из вас знают про лучшее на рынке программно-аппаратное решение для организации хранилищ под виртуализацию StarWind Virtual SAN. О прошлом его обновлении, которое вышло весной этого года, мы писали вот тут.

Недавно компания StarWind выпустила обновление этого продукта в виде виртуального модуля OVF на базе Linux для VMware vSphere - VSAN OVF Version 20201027 Version 8 (build 13861).

Давайте посмотрим, что там появилось нового:

Общие улучшения и багофиксы

• Обновлено ядро модуля Linux Kernel.
• Настройка iScsiPingCmdSendCmdTimeoutInSec теперь по умолчанию выставлена в 5 секунд.
• Исправленный процесс логирования для оповещений по email, теперь они не смешиваются с общими событиями почтового сервера.
• Улучшены операции по остановке службы (ранее этот процесс мог подвиснуть в определенных обстоятельствах).
• Обновлена имплементация SCSI-протокола для более корректного процессинга команд UNMAP/TRIM.

Улучшения синхронной репликации

• Добавлена опция использования SMB-шары как ресурса witness для устройств с синхронной репликацией.
• Исправлена обработка персистентных резерваций для устройств с синхронной репликацией.
• Исправлены некоторые случаи обновления состояния партнерского узла после восстановления из ситуации split-brain.

Управляющая консоль (Management Console)

• Исправлено падение консоли, когда StarWind Event log содержал записи с некорректными строковыми значениями.
• Обновлен диалог настроек нотификаций по email (добавлена валидация и спрятаны поля логина-пароля при отсутствии необходимости аутентификации).

Модуль StarWindX PowerShell

• Добавлена возможность добавления HA-устройств в конфигурации Node Majority. Теперь узел StarWind или SMB-шара могут быть использованы как witness. Более подробно об этом можно узнать из примеров сценариев CreateHAPartnerWitness.ps1 и CreateHASmbWitness.ps1.

• Поправлена обработка параметра ALUA для командлетов по созданию HA-устройства.

Скачать пробную версию StarWind Virtual SAN для VMware vSphere в формате виртуального модуля OVF можно по этой прямой ссылке.

Некоторое время назад мы писали о версии пакета VMware Tools 11, который теперь доступен и для Mac OS. На днях компания VMware сделала еще одно важное изменение в линейке VMware Tools - теперь это отдельный и самостоятельный продукт, а не часть платформы vSphere.

На практике это означает, что теперь тулзы имеют собственную политику жизненного цикла (Lifecycle policy), а также собственную матрицу поддержки, позволяющую пользователям понять, какой жизнью живут VMware Tools, и когда их нужно апгрейдить:

Также загружать VMware Tools стало более удобно. Раньше они были доступны на вкладке "Drivers and Tools" раздела загрузки vSphere, а теперь это отдельный продукт и находится он в "Product Downloads".

Скачать VMware Tools теперь можно по этой ссылке. Основная статья базы знаний на эту тему - KB 78528.

Многие администраторы VMware vSphere знают, что у этой платформы есть режим совместимости Enhanced vMotion Compatibility (EVC), который позволяет привести хосты с процессорами (CPU) разных моделей к единому базовому уровню по набору возможностей CPU Feature Set, чтобы обеспечить свободную миграцию vMotion между хостами ESXi. Делается это за счет маскирования некоторых наборов инструкций процессора через CPUID.

Сейчас многие приложения (например, реализующие техники Machine Learning / Deep Learning) используют ресурсы графического адаптера (GPU), поскольку их многоядерная архитектура отлично подходит для такого рода задач.

В VMware vSphere 7, вместе с соответствующей версией VM Hardware, были существенно улучшены функции работы для режима vSGA, который предназначен для совместного использования графического адаптера несколькими виртуальными машинами хоста.

Поэтому в VMware vSphere 7 Update 1 сделали еще одно полезное улучшение по этой теме - режим Enhanced vMotion Capabilities для графических процессоров GPU, который является частью EVC, настраиваемого в vSphere Client:

Графический режим VMFeatures включает в себя поддерживаемые возможности для 3D-приложений, включая библиотеки D3D 10.0/ Open Gl 3.3, D3D 10.1 / Open GL 3.3 и D3D 11.0 / Open GL 4.1. Пока приведение к базовому уровню доступно только до D3D 10.1 / OpenGL 3.3 (версии 11.0 и 4.1, соответственно, будут поддерживаться в следующих релизах).

Когда хост ESXi включается в кластер, где включена EVC for Graphics, сервер vCenter проверяет, что он поддерживает соответствующие версии библиотек. При этом можно добавлять хосты разных версий - ESXi 6.5, 6.7 и 7.0, благодаря поддержке D3D 10.0 и OpenGL 3.3.

Как и для обычного EVC, пользователи могут включить EVC for Graphics на уровне отдельных ВМ. В этом случае перед тем, как включить виртуальную машину на хосте ESXi, сервер vCenter убеждается, что он поддерживает соответствующие библиотеки. Такая настройка полезна при возможной миграции виртуальной машины между датацентрами или в публичное облако.

Если у вас включена EVC for Graphics, то перед миграциями vMotion также будут проводиться нужные предпроверки по поддержке графических функций GPU со стороны видеоадаптера целевого хоста.

VMware на днях выпустила патч VMSA-2020-0023, который окончательно закрывает уязвимость CVE-2020-3992, имевшуюся в сервисе OpenSLP хоста ESXi. Эта уязвимость типа Use-After-Free позволяла злоумышленнику, имевшему доступ к 427 порту, получить возможность удаленного исполнения кода (эта уязвимость имела критический статус и CVS score 9.8 из 10).

VMware заявляет, что данные патчи, выпущенные 20 октября, не закрывают уязвимость полностью, поэтому нужно скачивать самые последние версии патчей:

Вот сами обновления, которые были выпущены:

• ESXi 7.0 - ESXi70U1a-17119627. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi_7.0.1-0.0.16850804
• ESXi 6.7 - ESXi670-202011301-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi670-202010401-SG
• ESXi 6.5 - ESXi650-202011401-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi650-202010401-SG

Воркэраунд, описанный в статье базы знаний KB 76372, все еще актуален. Его суть заключается в полном отключении сервиса SLP с помощью следующих команд:

/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0
chkconfig slpd off

Обновляйтесь обязательно!